The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In a business-to-business environment, applications executing on computers commonly communicate with other applications that execute on other computers. For example, an application “A” executing on a computer “X” might send, to an application “B” executing on a computer “Y,” a message that indicates the substance of a purchase order.
Computer “X” might be remote from computer “Y.” In order for computer “X” to send the message to computer “Y,” computer “X” might send the message through a computer network such as a local area network (LAN), a wide-area network (WAN), or an inter-network such as the Internet. In order to transmit the message through such a network, computer “X” might use a suite of communication protocols. For example, computer “X” might use a network layer protocol such as Internet Protocol (IP) in conjunction with a transport layer protocol such as Transport Control Protocol (TCP) to transmit the message.
Assuming that the message is transmitted using TCP, the message is encapsulated into one or more data packets; separate portions of the same message may be sent in separate packets. Continuing the above example, computer “X” sends the data packets through the network toward computer “Y.” One or more network elements intermediate to computer “X” and computer “Y” may receive the packets, determine a next “hop” for the packets, and send the packets towards computer “Y.”
For example, a router “U” might receive the packets from computer “X” and determine, based on the packets being destined for computer “Y,” that the packets should be forwarded to another router “V” (the next “hop” on the route). Router “V” might receive the packets from router “U” and send the packets on to computer “Y.” At computer “Y,” the contents of the packets may be extracted and reassembled to form the original message, which may be provided to application “B.” Applications “A” and “B” may remain oblivious to the fact that the packets were routed through routers “U” and “V.” Indeed, separate packets may take different routes through the network.
A message may be transmitted using any of several application layer protocols in conjunction with the network layer and transport layer protocols discussed above. For example, application “A” may specify that computer “X” is to send a message using Hypertext Transfer Protocol (HTTP). Accordingly, computer “X” may add HTTP-specific headers to the front of the message before encapsulating the message into TCP packets as described above. If application “B” is configured to receive messages according to HTTP, then computer “Y” may use the HTTP-specific headers to handle the message.
In addition to all of the above, a message may be structured according to any of several message formats. A message format generally indicates the structure of a message. For example, if a purchase order comprises an address and a delivery date, the address and delivery date may be distinguished from each other within the message using message format-specific mechanisms. For example, application “A” may indicate the structure of a purchase order using Extensible Markup Language (XML). Using XML as the message format, the address might be enclosed within “<address>” and “</address>” tags, and the delivery date might be enclosed within “<delivery-date>” and “</delivery-date>” tags. If application “B” is configured to interpret messages in XML, then application “B” may use the tags in order to determine which part of the message contains the address and which part of the message contains the delivery date.
As is discussed above, a message may be divided into portions, and each portion may be transmitted in a separate IP packet toward the message's destination. The TCP protocol implements mechanisms for ensuring that IP packets may be assembled in their proper order relative to each other, and that no IP packet will be duplicated.
When a destination application (e.g., application “B” in the example above) receives a TCP packet, the destination application sends an acknowledgment back toward the packet's source. The acknowledgement identifies the packet by the packet's sequence number. If the source application (e.g., application “A” in the example above) receives the acknowledgement within a specified interval of time after sending the corresponding packet, then the source application will be confident that the destination application received the packet. As a result, the source application does not need to re-send the packet. Alternatively, if the source application does not receive the acknowledgement within a specified interval of time after sending the corresponding packet, then the source application re-sends the packet. The packet may be re-sent until the source application receives an acknowledgment.
Under some circumstances, a proxy device receives packets from a source application and then forwards the packets to the destination application. Under these circumstances, the proxy device sends acknowledgements back to the source application. It is possible that the proxy device might send an acknowledgment to the source application, but the packet corresponding to the acknowledgment might not successfully reach the destination application. For example, this might happen if the connection between the proxy device and the destination application is broken, or if the destination application fails. Under these circumstances, the source application still will receive the acknowledgement from the proxy device and, consequently, will not re-send the packet even though the packet never reached the destination application.
Thus, under some circumstances, such as those described above, the TCP protocol does not guarantee that a particular TCP packet actually will reach a destination application. As a result, there is no guarantee that a message at least partially contained within the particular TCP packet will reach the destination application.
A technique for guaranteeing that a message sent from a source application will be received by a destination application is needed.